SetDirectory["/data/Mathematica/knots/"]

<<KnotTheory`

Jones polynomial from a planar diagram (discussion on the writhe bias)

The PD function requires the crossings to be oriented in the lower component - they need information where the line comes in and where it goes out. However, the convention of counter clock wise specification means that the upper line has no degree of freedom to specify orientation. This line from the Knot Atlas website :

The (sometimes ambiguous) orientation of the upper strand is determined by the ordering of {j, l}.

I do not really understand. {j, l} order is prescribed by the orientation exactly. In a whole link, the orientation is indeed uniquely defined by only specifying orientation of the lower lines. I' m mentioning this, because it' s possible this statement is related to the issue I found with the Gauss codes (I get to that later in the document).

At first, I thought the crossings were not required to be oriented. Connectivity information is quite enough to orient links automatically (up to component reversals). Such a function would come handy, because orienting the crossings is a tedious business.

Additionally, the problem of ambiguity for kinks (crossings with two equal labels - connected to itself) would go away if the computation was not sensitive to crossing orientation.

For all demonstrations I use a particular example of an unknot, but the issues I raise are present in a lot of cases.

I found that using wrongly oriented crossings (sometimes starting at outgoing side of the lower strand) produced a Jones polynomial distinct from 1 for an unknot. It was a monomial with a seemingly random exponent. Therefore I here use a properly oriented planar diagram.

l={{2,3,1,1},{5,6,4,4},{7,7,8,9},{12,13,10,2},{6,11,13,14},{15,16,9,8},{21,12,19,20},{22,23,17,21},{16,18,24,25},{30,30,26,19},{28,27,31,31},{25,29,32,32},{10,11,5,3},{17,18,15,14},{26,27,22,20},{24,23,28,29}}

pd=PD@@(X@@#&/@l)

This should be 1, as this is unlink, but it still has a leftover monomial (it’s not even symmetric to reflection)

{Jones[pd][x],Jones[Mirror[pd]][x]}

It' s not even just Kauffman bracket with missing correction (-x^(-3/4))^(-writhe).

writhe=PositiveCrossings[pd]-NegativeCrossings[pd]

(-x^(-3/4))^(-writhe)

Maybe the kinks (the twisted ears) are the problem, as briefly mentioned on the Knot Atlas. Remove all of them:

l2=FixedPoint[DeleteCases[#/.(Rule@@(First/@Cases[Tally[#],{_,1}])&/@Cases[#,{x_,x_,_,_}|{_,_,x_,x_}|{_,x_,x_,_}|{x_,_,_,x_}]),{x_,x_,y_,y_}|{x_,y_,y_,x_}]&,l]

pd2=PD@@(X@@#&/@l2)

Now it works (so apparently the kinks are really at fault here).

Jones[pd2][x]

As the code reacts badly to kinks, they could always be removed automatically as I did above, to make the package more robust and error - proof.

Again - properly oriented crossings seem to be required for this to work properly, and kinks become ambiguous if orientation is required. For internal use, this is ok, but it would help to have a way of automatically orienting the crossings (X[1, 2, 3, 4] ⇔ X[3, 4, 1, 2], RotateLeft/Right function in Mathematica) to produce a valid diagram. This could be immense help to programmatically read out a hand-drawn input knot diagram. Without orienting the crossings, the specification seems to be inconsistent and does not represent any valid knot.

Problems with Gauss codes

The same diagram as above (with kinks already cut off) can be represented with a Gauss code :

g={6,2,7,5,9,4,-3,-8,-4,-7,-5,-9,8,3,-1,-6,-2,1}

gc=GaussCode[g]

Now this below is very obviously wrong

Jones[gc][x]

Maybe the internal Gauss -> PD conversion has problems :

pdgauss=PD[gc]

Jones[pdgauss][x]

Trying to reconstruct the PD obtained from above Gauss Code leads to a diagram that is NOT planar. It leads to unreconcilable topological constraints :

{}

To make the diagram planar again, two crossings have to be flipped (see in red).

{}

pdgaussfixed=PD[X[15,18,16,1],X[17,2,18,3],X[7,14,8,15],X[9,7,10,6],X[11,5,12,4],X[16,2,17,1],X[10,3,11,4],X[9,13,8,14],X[12,5,13,6]]

I didn' t check if the diagram is planar isotopic to the original one, but at least it' s an unknot (and Jones polynomial gives a simple monomial in x, but still not 1, as it is not oriented properly now).

Jones[pdgaussfixed][x]

I’m not sure if I’m doing anything wrong here, but the Gauss→PD conversion seems to produce a non-planar graph if we take into account the counter-clockwise rule, and thus does not correspond to any representable knot. I’m not sure if this problem arises from shuffling around components under assumption that in X[i,j,k,l], {j,l} can be exchanged (which is incorrect), or if there is some problem with requiring proper orientation internally in the PD[_GaussCode] function which propagates to producing a bogus result. If this is indeed a bug, I’m just reporting it to avoid problems for other users. If there is an error in my understanding of how this package works, please point out my mistake.

Kauffman F polynomial problem and other things I did not expect

This function appears to have have problems for this particular diagram (even though it should work)

Kauffman[pd2][a,z]

It does work for builtin polynomials

Kauffman[Knot[5,2]][a,z]

Checking if this is because the edge numbers are no longer sequential - renumber to avoid gaps

l3=(#/.MapIndexed[Rule@@Flatten[{##}]&,Union[Flatten[#]]]& )[l2]

pd3=PD@@(X@@#&/@l3)

Still doesn' t work.

Kauffman[pd3][a,z]

This is ok

Alexander[pd3][x]

But this should be 1

HOMFLYPT[pd3][a,z]

Sometimes the wrong part of the circular arc is drawn

DrawPD[pd3]

Jones is still not invariant to back-and-forth even with our "nice" well-oriented de-kinked input

DTCode[pd3]

Jones[pd3][x]

Jones[DTCode[pd3]][x]

Conversion back to GaussCode outputs gibberish (it' s not even a valid Gauss code, 1 is repeated)

GaussCode[pd3]